Yep, that's a bad API. What do you think about #51? It's breaking, but IMO, makes a lot more sense than this API.

Personally I like this API since it allows you to toggle verification functionality at runtime without needing to teardown existing applications + restart just to get the verification functionality. There are benefits to the change proposed in #51, however it will require projects to deal with the breaking change, which isn't necessarily the easiest thing depending on how heavily used HashOnRead is by some other projects.

It might make sense to implement both fixes, so projects can pull in the race condition fix without needing to deal with breaking changes until they're ready.

I'm merging this for now given that it does fix the bug. However, I'm still uncomfortable with the API.

Implementations: https://grep.app/search?q=func.%2A%20HashOnRead%5C%28&regexp=true&case=true

Other than this implementation:

• Two panic (not implemented).
• One does nothing.
• All others are wrappers that forward to the underlying blockstore.

That really smells like a bad API.

If this is meant for 0.5.0 it needs to be backported to a blockstore 0.1.x branch. (I can do, let me know).

This doesn't need to go into the release (we never call this after initializing the blockstore.